home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / ABERMUD.ZIP / MANUAL < prev    next >
Text File  |  1989-07-08  |  9KB  |  245 lines
  1.             A B E R M U D
  2.  
  3.         A guide to the system and its use
  4.  
  5.  
  6. Contents
  7.  
  8.     1.    Idea of the game
  9.  
  10.     2.    Commands For The Privileged
  11.  
  12.     3.    How It Works
  13.  
  14.     4.    Security Aspects
  15.  
  16.     5.    Extending The System
  17.  
  18.     6.    Installation Guide
  19.  
  20.     7.    Portability Aspects
  21.  
  22.  
  23.  
  24. Introduction
  25.  
  26.     
  27.     AberMUD is a multi user adventure system for up to 16 players, it is
  28. designed to run on almost anything with a processor in it, and has been 
  29. succesfully run originally on a Honeywell L66 under GCOS 3, as well as
  30. UNIX Sun 3.4 . Indeed the orginal system was written in B , which is why the
  31. system is full of wonderful type conversions and twiddles.
  32.     The game is currently a fantasy scenario , but could easily be 
  33. changed to any other idea.
  34.     Note that AberMUD is far from the complete multi-user game system, its
  35. a simple system that works and was intended to be such, there's huge scope
  36. for improvement, so if you don't like something, then change it!
  37.  
  38.  
  39.  
  40. Idea Of The Game
  41.  
  42.     The idea of the current game is to score 140,000 points and become a 
  43. wizard. Points are scored for dropping treasure into the sacrificial pit
  44. at the temple, and the one at the village church. Points can also be scored
  45. for killing mobiles (although within the current system they aren't that 
  46. mobile!), and of course for killing players, which is a pastime many players
  47. like to have a go at.
  48.     The game has a complete combat system , which considers weapons and
  49. shields, and also allows people to flee from fights. To complement this the
  50. game also has a magic system with several spells of both informational,
  51. combat and utility nature.
  52.  
  53.  
  54. Commands
  55.  
  56.     The game system supports all the basic adventure type commands
  57. like take the sword, drop the axe, as well as a whole host of commands
  58. which are needed for a multi-user system. Some of these commands are
  59.  
  60. WHO    :    Show the players on the game, of course certain more
  61.         powerful beings may not wish to show up on the list..
  62.  
  63. SHOUT   :    Shout a message across the game, normally used for uttering
  64.         those nasty death threats to the person who killed you for
  65.         the fourteenth time this week.
  66.  
  67. TELL    :    Allows you to tell a player something. Although really you
  68.         you ought only to be able to tell something to someone in the
  69.         same room we found the game as a whole works better with 
  70.         tell as it currently is. Similarly you could argue that who
  71.         is unrealistic, but the results of its absence are simply a lot
  72.         of "Whos playing ?" shouts
  73.  
  74. SAY    :    Says something to everyone else in the room. Assuming they
  75.         haven't been deafened.....
  76.  
  77. STEAL   :    For all those moments when some other player or mobile
  78.         has something you fancy - just dont get caught at it!
  79.  
  80. GIVE    :    If you are feeling generous  you can donate goodies to other
  81.         players
  82.  
  83. KILL    :    Your oppotunity to beat mobiles and players to death.
  84.  
  85. WIELD   :    Select something as your weapon to hand, for when those
  86.         nasty people decide to brain you.
  87.  
  88. SAVE    :    Saves your characters current score and status. The things
  89.         you carry and wear are not saved.
  90.  
  91. QUIT    :    Exits the game, saving the character automatically. All your
  92.         belongings will be left where you quit, and should you 
  93.         re-enter the game it will be carrying nothing and at one of
  94.         the start positions.
  95.  
  96.  
  97. Life And Death
  98.  
  99.     All the scoring points is fine, but there is one important problem
  100. with life in the game, that is dying. There are two ways of dying in the game
  101. dying through little accidents with puzzles is a non fatal event which simply
  102. kicks you off the game, while dying in a fight is FATAL, that is your
  103. character will be no more, and its back to 0 points. Most players will
  104. rapidly get the hang of dying, living takes a little longer to master.
  105.  
  106.  
  107.  
  108. 2.    Commands For The Privileged
  109.  
  110.     Once a player achieves the status of wizard he/she gets the right to use
  111. a great many more powers, such as ZAP which can be used to totally destroy a
  112. person, exorcise to kick players off the game, and a vast range of 
  113. miscelleaneous wonders like POSE, DIR, LOC,goto any room...
  114.     The system assumes that wizards in return for having these powers have
  115. a certain amount of responsibility for the way they use them. We haven't had to
  116. turn any wizards back into mortals yet, but if needs be ...
  117.  
  118.  
  119. 2b.    Commands for the really privileged
  120.  
  121. RMEDIT:        Enter the internal room editor (we use emacs). This command also
  122.         inherently allows its user to shell out as the game id, see
  123.         security.
  124.  
  125. SHELL:        Sends all commands as if they had TSS in front until ** is typed
  126.         commands beginning * are treated as normal commands
  127.  
  128. TSS:        The name of this command is a historical accident to do with
  129.         GCOS3, but basically it passes the current command via
  130.         system().
  131.  
  132. RAW:        Allows superusers to make announcements. Certain very 
  133.         privileged people can send totally raw messages.
  134.  
  135. SYSTAT:        Not used under unix - we couldnt work out an easy PORTABLE
  136.         way to find out how much memory the program was running in
  137.         It was needed under GCOS as we were running close to 
  138.         installation size limits for programs.
  139.  
  140. INUM:        Returns the internal number of an item - or -1 if it doesnt
  141.         exist. Mainly used when debugging new parts of the game
  142.  
  143. DEBUGMODE:    Enter debug mode, this is subject to a PFLAG so it can be 
  144.         used with mortals too. It gives all the messages passed and
  145.         information on item numbers along with the normal game data
  146.  
  147. PATCH:        Allows DIRECT editing of the game world file. Not to be used
  148.         lightly, it just happens to be handy when debugging at times
  149.  
  150. PFLAGS:        Allows editing of a users privileges
  151.  
  152.  
  153. Of course all the other useful commands like SET and DIR are also available
  154.  
  155.  
  156. Registering wizards
  157.  
  158.     The way we handled wizards within the system is to let them choose
  159. a suitable name and to assign that name to a suitable spare level in
  160. objsys.c and recompile. Finally FROB the player to the correct level. The levels
  161. for wizards should be in the range 10-9999.(lotta wizzes!)
  162.  
  163.  
  164. 3.    How It Works
  165.  
  166.     AberMUD is actually a very simple multi user game system working
  167. entirely with files, which while slower than the UNIX gurus beloved sockets
  168. is far more portable. Indeed AberMUD should run quite happily on SYS V with
  169. few changes (The only obvious one being to the use of getpass()).
  170.     The system shares game data in a single 153K or so file, which holds
  171. all the player data and some of the object data. In addition it also includes
  172. a message passing mechanism which allows messages to be sent to players or
  173. rooms or whatever.
  174.     Each player inspects this file regularly (on a 2sec alarm) and when
  175. changing it, so as to keep up with the world. Flock() is used to lock the file
  176. hence one important restriction - the system cannot run across networked hosts
  177. This is for one simple reason - lockf() on our suns was having little accidents
  178. like locking the entire Network Filing System so I had to resort to flock
  179. which is both faster and avoids getting the system manager cross.
  180.     All the user output is buffered via a routine called bprintf() which
  181. serves to ensure no smart alec can hit CTRL-S while he has the file locked, and
  182. also helps to improve performance.
  183.     Thats about it really, the rest of the game logic and coding is no
  184. different to a single user game.
  185.  
  186.  
  187. 4.    Security Aspects
  188.  
  189. Certain users may shell out of AberMUD, they are - any user with the RMEDIT
  190. pflag , or obviously the EDITPFLAG pflag, and any Arch_Wizard (level>9999)
  191. who is already on the game id. No one else is capable of shelling out - save
  192. to the bulletin board - hence the rather peculiar "Honeyboard" command lying 
  193. around, you may wish to improve this.
  194.  
  195. 5.    Extending The System
  196.  
  197.     The system is designed to be easy to extend and patch, its whole basis
  198. being to keep it simple but working. The objects for the game and the mobiles
  199. can both be expanded by editing the obdat and reset player data. In addition
  200. for objects they need to be added to the ob.in file and ogenerate run over it
  201. to produce a file called ob.out which should then be copied to the RESET_DATA
  202. file.
  203.     The current system is far from perfect, it was written originally as a
  204. joke, so don't blame me!, but at least this means there is plenty of scope
  205. for frobnicating with the code.
  206.  
  207.  
  208. Installation Guide
  209.  
  210.     Make a directory called ABERMUD or something similar then in that 
  211. directory , and on the correct host execute.( If your machine does not 
  212. support gethostname() then you should remove the sections using it from
  213. make.h.c, and gmain2.c)
  214.  
  215. sh <shar
  216. sh <shar1
  217. sh <shar1b
  218. sh <shar2
  219. sh <install.sh
  220. sh <shar3
  221. sh <shar4
  222. sh <shar5
  223. sh <shar6
  224. sh <shar7
  225. sh <shar8
  226. sh <install2.sh
  227.  
  228. and the system will be installed!!!
  229.  
  230. You will probably want to change the ids recognized as "special" in gmlnk.c.
  231. and also the trap for Anarchy being the user with the automatic right to edit
  232. PFLAGS, in support.c
  233.  
  234.  
  235. 7. Portability Aspects
  236.  
  237.     So far as I know the only things which may cause porting problems
  238. across different versions of UNIX is the flock call and the use of getpass
  239. which behaves differently on Sys V - it will need a trap for a null return
  240. which should then exit with crapup("Not a terminal"); or something similar
  241.     The code should port reasonably to other systems
  242.  
  243.  
  244. END
  245.